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(54) Methods, apparatus and data structures for managing objects 



(57) A variety of methods, apparatus, and data 
structures for managing transient and persistent distrib- 
uted objects are disclosed. Objects for use as object ref- 
erences are described, both for transient and persistent 
objects. In one aspect of the invention, a data structure 
that is intended for use as an object reference for a tran- 
sient object is disclosed having a set of endpoint ad- 
dresses, an incarnation number, and an object key. 
These elements serve to uniquely identify and locate the 
transient object. In another aspect of the invention, an 
object that is intended for use as an object reference for 
a persistent object is disclosed having a host computer 
name, a locator identification, an object key, and a sub- 
object identifier. The first three elements serve as an in- 



direction to the persistent object and the third element 
is for use by the persistent object. These data structures 
enable a distributed object operating environment which 
integrates both transient and persistent objects. A vari- 
ety of methods utilizing one or more of the elements of 
the abovementioned object references to provide a sys- 
tem resource efficient interaction between a client re- 
questing service from a server object. One particular 
method selects the fastest transport mode between the 
client and the server object. Another specific method 
teaches reading addressing information directly from lo- 
cal cache memory. If the addressing information is not 
available in cache memory, the information is first found 
and then stored in cache memory thereby perpetuating 
the efficiency of the invention. 



< 

o> 

h- 

co 

o 

Q. 
LU 



Printed by Jouve, 75001 PARIS (FR) 



1 



EP 0 737 916 A1 



2 



Description 

BACKGROUND OF THE INVENTION 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods, apparatus and data 
structures for managing transient and persistent ob- 
jects. 

Object oriented programming methodologies have 
received increasing attention over the past several 
years in response to the growing tendency for software 
developed using traditional programming methods to be 
delivered late and over budget. This stems from the fact 
that traditional programming techniques that emphasize 
procedural models and "linear" code tend to be difficult 
to design and maintain in many circumstances. Gener- 
ally, large programs created using traditional methods 
are "brittle". That is, even small changes can effect nu- 
merous elements of the programming code. Thus, minor 
changes made to the software in response to user de- 
mands can require major redesign and rewriting of the 
entire program. 

Object oriented programming strategies tend to 
avoid these problems because object methodologies fo- 
cus on manipulating data rather than procedures; thus 
providing the programmer with a more intuitive ap- 
proach to modeling real world problems. In addition ob- 
jects encapsulate related data and procedures so as to 
hide that information from the remainder of the program 
by allowing access to the data and procedures only 
through the object's interface. Hence changes to the da- 
ta and or procedures of the object are relatively isolated 
from the remainder of the program. This provides code 
that is more easily maintained as compared to code writ- 
ten using traditional methods, as changes to an object's 
code do not affect the code in the other objects. In ad- 
dition, the inherent modular nature of objects allows in- 
dividual objects and interfaces to be reused in different 
programs. Thus, programmers can devebp libraries of 
"tried and true" objects and interfaces that can be used 
over and over again in different applications. This in- 
creases software reliability while decreasing develop- 
ment time, as reliable programming code may be used 
repeatedly. 

A more recent advance in the field of object oriented 
methodologies has been the implementation of distrib- 
uted object operating environments over computers in- 
terconnected via a computer network. As used herein, 
the term "distributed object" or "object" refers to an en- 
capsulated package of code and data that can be ma- 
nipulated by operations through an interface. Thus, dis- 
tributed objects will be seen by those skilled in the art 
of object oriented programming (OOP) as including the 
basic properties that define traditional programming ob- 
jects. However, distributed objects differ from traditional 
programming objects by the inclusion of two important 



features. First, distributed objects are multilingual. That 
is, the interfaces of distributed objects are defined using 
an interface definition language (IDL) that can be 
mapped to a variety of different programming languag- 
5 es. One such interface definition language is the Object 
Management Group's IDL. Second, distributed objects 
are location-independent, i.e., distributed objects can 
be located anywhere in a network. This contrasts sharp- 
ly with traditional programming objects which typically 
io exist only in a single address space which is shared with 
the their clients. 

Distributed objects can be object clients or object 
servers, depending upon whether they are sending re- 
quests to other objects or replying to requests from cli- 
is ents. In a distributed object environment, requests and 
replies are made through an Object Request Broker 
(ORB) that is aware of the locations and status of the 
objects. One architecture which is suitable for imple- 
menting such an ORB is provided by the Common Ob- 
ject Request Broker Architecture (CORBA) specifica- 
tion. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 
in a distributed client-server environment, where server 
objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
terchangeably. 

In the field of distributed object environments, there 
are potentially two predominant kinds of objects, the 
transient object and the persistent object. Transient ob- 
jects typically have a short life span and are bound to a 
single host process. That is, when a host process ceas- 
es, all transient objects running under the process also 
cease. Thus there is no continuity of identity of a tran- 
sient object from one process to another. Because tran- 
sient objects are bound to a single process, they inher- 
ently cannot change their location. Hence transient ob- 
jects could also be renamed "immobile" objects, as their 
addresses never change. 

In contrast, persistent objects are not bound to a 
single process and their location may change overtime. 
Thus persistent objects could be called "mobile" objects, 
as their addresses may change. With a persistent ob- 
ject, there is continuity of identity from one process to 
another. However, a persistent object can exist in only 
one process at a time. 

When discussing the transient or persistent nature 
of an object, what is typically being envisioned is the 
transient or persistent nature of the object state. As will 
be well familiar to those skilled in the art, a computer 
entity such as a process or an object may have two com- 
ponents: executable code and state. Executable code 
is essentially the instructions by which the entity oper- 
ates. Thus state is the remaining portion such as data 
which is not code. The motivation behind different kinds 
of state, e.g. transient and persistent, is fairly straight 
forward. Persistent state requires additional system re- 
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sources such as mass-storage devices and correspond- 
ing management resources to ensure persistence, 
which may or may not be desired. For example, infor- 
mation stored in a database is typically intended for long 
term storage, and thus persistence is required. In situ- 
ations such as this it is well worth the extra system re- 
sources required to maintain this data. 

However, there are a variety of scenarios where 
persistence is not required and thus the extra system 
resources required for persistent state are in effect wast- 
ed. Any situation where the state is necessary only for 
a short period and/or if needed later can be easily rec- 
reated is a candidate for transient state. A familiar ex- 
ample of this is icons such as formatting and editing but- 
tons in many window based word-processing programs. 
When implementing buttons such as these, there will be 
(roughly speaking) code which makes them operate and 
state which gives them their appearance. This state 
would include the bit map of the icon. When the word- 
processing window is closed, the icon disappears and 
there is no need to maintain the bit map of the different 
icons. By using transient state, the system can forget 
about maintaining these bit maps until they are needed 
again, at which time they can be recreated. 

Prior solutions for dealing with transient and/or per- 
sistent state fail to provide a framework which effectively 
enables the integration of transient and persistent ob- 
jects within a distributed object operating environment. 
For example, database technology, including object ori- 
ented database technology, has generally dealt only 
with maintaining persistent state. As another example, 
personal computing systems are designed so that all re- 
sources and services start up the same each time by 
utilizing persistent state. The well known Distributed 
Computing Environment (DCE) implements only per- 
sistent distributed objects, using a 128 bit identifier to 
manage each individual object. In general, prior tech- 
nology deals mostly with persistent objects, and if it does 
deal with transient objects, it tends to focus on only tran- 
sient objects. What is needed is a framework for effi- 
ciently integrating transient and persistent objects under 
a distributed object operating environment This will re- 
quire data structures which will allow for the differences 
between the two yet still provide an integrated frame- 
work. Moreover, effective methods for managing these 
persistent and transient objects will be required. 

SUMMARY OF THE INVENTION 

To achieve the foregoing and other objects and in 
accordance with the purpose of the present invention, 
methods, apparatus, and data structures for managing 
transient and persistent objects are described. In one 
aspect of the invention, a data structure which is intend- 
ed for use as an object reference for a transient object 
includes a set of endpoint addresses, an incarnation 
number, and an object key. The set of endpoint address- 
es is arranged to correspond to a server host computer 



upon which the transient object resides. The incarnation 
number is arranged to correspond to a server host proc- 
ess which is executing on the host computer. The tran- 
sient server object may run only in this server host proc- 

5 ess. The object key is an identifier which corresponds 
to the transient server object. These three elements, the 
set of endpoint addresses, the incarnation number, and 
the object key, serve to uniquely identify and locate the 
transient server object. Additionally, various embodi- 

10 ments and a variety of methods for utilizing one or more 
of these elements to enable efficient interaction be- 
tween a client requesting services and the transient 
server object are also described. 

In some applications the length of these data ele- 

?5 ments may be variable, whereas in other applications 
the length may be fixed. In the fixed case, a length in 
the range of about 1 - 128 bytes is preferred. In one par- 
ticular embodiment, one address from the set of end- 
point addresses includes a 4 byte long server host net- 

20 work address and a 2 byte long server process network 
port number. In another particular embodiment, the in- 
carnation number is essentially a date stamp. That is, a 
monotonically increasing number indicating the creation 
time of the server process. In other embodiments, the 

25 incarnation number is a predefined number which has 
a predefined meaning to the server process. 

In one specific embodiment, the object key is an 
identification number unique within the server process 
that hosts the transient server object. In yet another em- 

30 bodiment, the object key is used to transport an object 
reference which is formatted according to the protocol 
of a different distributed object operating environment. 

According to another aspect of the present inven- 
tion, the data structure of the object reference includes 

35 an internal name indicating that the object kind is tran- 
sient. 

In another aspect of the invention, a transient object 
corresponding to the abovementioned object reference 
is contemplated. The transient object has state, but this 

40 state is strictly transient state. In further embodiments 
the transient object is bound to the server process and 
therefore has continuity of identity within and only within 
the server process. 

In a apparatus aspect of the invention, a distributed 
object operating environment includes a plurality of 
computer systems, a computer network interconnecting 
the computer systems, and at least one object for use 
as an object reference for a transient server object. In a 
further apparatus embodiment, the distributed object 

50 operating environment also includes a second object for 
use as an object reference for a persistent server object. 
The second object has a data structure which includes 
a host computer name, a locator identification, an object 
key, and a subobject identifier. The second object's data 

55 structure may optionally include a location hint and a 
kind field which indicates that the object kind is persist- 
ent. 

In the data structure of the second object, the host 
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computer name will correspond to a host computer 
which has a server object locator service running on it. 
The locator identification will correspond to a process 
within which a server object locator object exists. The 
locator object is one component of a locator service, the 
locator object being consulted to establish location in- 
formation for the second object. The location informa- 
tion will include data similar to the first object data struc- 
ture such as a set of endpoint addresses and an incar- 
nation number. 

In separate aspects of the invention, various meth- 
ods of managing transient and persistent objects during 
the calling of a distributed server object which runs on 
a server process residing on a server host computer are 
described. In one method aspect, the client has an ob- 
ject reference to a server object and the client call in- 
cludes the steps of acquiring addressing information for 
the distributed server object, selecting an address for 
the distributed server object, and sending a request to 
the distributed server object. In a further embodiment 
this method includes the step of receiving a response 
from the distributed server object. 

In another method aspect, the step of acquiring ad- 
dressing information includes the substep of determin- 
ing the kind of the distributed server object, the kinds 
including transient, persistent, null, and invalid. Then, 
depending on the kind of the distributed server object, 
different methods may be performed. If the kind is null 
or invalid, an error message is returned. If the kind is 
transient, then addressing information is returned direct- 
ly from the object reference. If the kind is persistent, then 
the step of acquiring addressing information includes 
further steps such as determining if the addressing in- 
formation is stored in cache memory on the client host 
computer and returning the addressing information di- 
rectly from the cache memory. If the addressing infor- 
mation is not stored in cache memory, then the address- 
ing information is obtained from within the distributed 
object operating environment, stored in cache memory, 
and then returned directly from the cache memory. 

In a further method aspect, the step of selecting an 
address includes determining if said client and said 
server are in the same process, and if so, a local address 
and a local transport mode are selected. In another 
method aspect, if the client and server are in different 
processes, shared memory addressing and shared 
memory transport are selected if the server host com- 
puter is the same as the client host computer. However, 
if shared memory addressing is not available or if the 
server host computer is not the same as the client host 
computer, then remote addressing and remote transport 
is selected. 

In a separate method aspect, a method for main- 
taining distributed object addressing information in a 
cache memory on a host computer in a distributed object 
operating environment is disclosed. This method begins 
when an object reference corresponding to a distributed 
object is received. Then, if the object reference includes 



addressing information for the distributed object, this ad- 
dressing information is written into the cache memory. 
In some embodiments the object reference is received 
as part of a target object call, while in other embodi- 

5 ments it is received in response to a target object call. 
In any event, the step of receiving may include unmar- 
shaling the object reference prior to determining if any 
addressing information is available. 

In a method aspect related to the preceding para- 

io graphs discussion, a multiplicity of host computers 
which are part of a distributed object operating environ- 
ment each have their own cache memory. Each of these 
computers performs the method of the preceding para- 
graph in order to increase the addressing information 

15 available in their cache memory. Furthermore, if any of 
the host computers locates new addressing information, 
it perpetuates the advantages of the present invention 
by marshaling it into an object reference and distributing 
it to the other host computers which are part of the dis- 

20 tributed object operating environment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further objects and ad- 
25 vantages thereof, may best be understood by reference 
to the following description taken in conjunction with the 
accompanying drawings in which: 

FIGURE 1 is a pictorial illustration of various com- 
30 puters linked together in a computer network. 

FIGURE 2 illustrates diagramatically the major 
components of a computer in Figure 1 . 

35 FIGURE 3a is a pictorial illustration of a host-to-host 
client-server model showing the relationship be- 
tween a client running on a client host computer and 
a server object running on a different, server host 
computer in a distributed object operating environ- 

40 ment; 

FIGURE 3b is a pictorial illustration of a process-to- 
process client-server model showing the relation- 
ship between a client and server running in different 
45 processes on a client/server host computer; 

FIGURE 3c is a pictorial illustration of a client-server 
model showing the relationship between a client 
and server running in a single client/server process; 

so 

FIGURE 4a is a pictorial illustration of a persistent 
object showing a progression through three differ- 
ent object states, each state including transient 
state and persistent state in accordance with a first 
55 aspect of the present invention; 

FIGURE 4b is a pictorial illustration of a transient 
object in accordance with a second embodiment of 
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the present invention showing a progression 
through three different states, each state including 
transient state in accordance with a second aspect 
of the present invention; 

FIGURE 5a is a pictorial illustration of an object ref- 
erence for a transient object, the object reference 
including a kind field, a set of endpoint addresses, 
an incarnation number, and an object key in accord- 
ance with a second embodiment of the present in- 
vention; 

FIGURE 5b is a pictorial illustration of an object ref- 
erence for a persistent object, the object reference 
including a kind field, a host name, a locator identi- 
fication, an object key, a subobject identifier, and a 
location hint in accordance with a first embodiment 
of the present invention; 

FIGURE 6 is a flow chart illustrating a process ex- 
ecuted by a client to invoke a distributed server ob- 
ject in accordance with one method aspect of the 
present invention; 

FIGURE 7 is a flowchart illustrating in further detail 
a step 604 of FIGURE 6; 

FIGURE 8 is a flowchart illustrating in further detail 
a step 606 of FIGURE 6; 

FIGURE 9 is a flow chart illustrating in further detail 
a step 716 of FIGURE 7; 

FIGURE 10 is a flow chart illustrating in further detail 
a step 904 of FIGURE 9; and 

FIGURE 11 is a flow chart illustrating a process for 
perpetuating the advantages of the present inven- 
tion by increasing the addressing information avail- 
able in cache memory. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention relates to a distributed oper- 
ating environment based on object oriented program- 
ming (OOP). More specifically, this invention discloses 
methods, apparatus and data structures for managing 
objects. The kinds of objects which are discussed in- 
clude transient and persistent objects. A transient object 
maintains no persistent state and is tied directly to the 
life of the process under which it is running. By way of 
explanation, persistent state is that state which persists 
(or bridges) from one process to another. On the other 
hand, a persistent object can have both persistent and 
transient state and typically persists over a length of 
time. In the fol towing discussion, the different kinds of 
objects will be described in more detail, first through dis- 
cussing example computer systems which are suitable 



for the present invention, next continuing with a detailed 
description of several embodiments of the apparatus 
and data structures of the present invention, and then 
further through the detailed description of the method 
5 aspects of the present invention. 

I. DEFINITION OF TER MS 

As used herein, the term "distributed object" or "ob- 
10 jeer refers to an encapsulated package of code and da- 
ta that can be manipulated by operations through a de- 
fined interface that is associated with an object. Thus, 
distributed objects will be seen by those skilled in the 
art as including the basic properties that define tradition- 

is al programming objects. However, distributed objects 
differ from traditional programming objects by the inclu- 
sion of two important features. First, distributed objects 
are multilingual. The interfaces of distributed objects are 
defined using an interface definition language that can 

20 be mapped to a variety of different programming lan- 
guages. One such interface definition language is OMG 
IDL. Second, distributed objects are location-independ- 
ent, Lb., distributed objects can be located anywhere in 
a network. This contrasts sharply with traditional pro- 

25 gramming objects which typically exist in a single ad- 
dress space: the address space of the "client." Distrib- 
uted objects can be object clients or object servers, de- 
pending upon whether they are sending requests to oth- 
er objects or replying to requests from other objects. Re- 

30 quests and replies are made through an Object Request 
Broker (ORB) that is aware of the locations and status 
of the objects. 

A "distributed object system" or "distributed object 
operating environment" refers to a system comprising 

35 distributed objects that communicate through an ORB. 
An "object reference" or "objref ■ is data structure (it 
may be a traditional programming language object) that 
contains a pointer to another object. The creation and 
definition of object references will be familiar to those 

40 skilled in the art. 

A "client" as defined herein refers to an entity that 
sends a request to an object. In this model, the object 
provides a service and is referred to as a "server object" 
or a "target object". Thus, clients invoke operations, or 

45 implementations, from servers. In some cases, clients 
are themselves objects. In a distributed object environ- 
ment, clients need not have knowledge of the implemen- 
tation programming language, nor does the implemen- 
tation have to have knowledge of the client's program- 

50 ming language due to the requirement of multilingual 
character of such objects. Clients and servers in distrib- 
uted object operating environments need only commu- 
nicate in terms of the interface definition language. As 
noted above, the request by the client to the server, and 

55 the server's reply to the client, is handled by the ORB. 
It should be pointed out that the client and server can 
exist within the same process, on the same host com- 
puter, or on two different host computers. 
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An 'object interface" is a specification of the oper- 
ations, attributes, and exceptions that an object pro- 
vides. Preferably, object interfaces for distributed ob- 
jects are written using an IDL. As noted above, objects 
perform transactions through their interfaces. The use 
of interfaces therefore eliminates the need of clients to 
be aware of the programming languages used to define 
the methods and data of the objects in the transaction. 

To "marshal' a packet of information is to prepare 
this information for transfer either through a shared 
memory communications channel or over a network 
communications line. This often means organizing the 
data in a particular format in accordance with the com- 
munications protocol being used. 

To "unmarshal" a packet of information is to essen- 
tially reverse the marshaling procedure and produce da- 
ta in a format which is meaningful in the appropriate en- 
vironment. 

II. Managing Objects 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods, apparatus and data 
structures for managing transient and persistent distrib- 
uted objects. 

As used herein, the term "distributed object" or "ob- 
ject" refers to an encapsulated package of code and da- 
ta that can be manipulated by operations through an in- 
terface. Additionally, the distributed object of the present 
invention may include features such as described in the 
background. For example, distributed objects can be 
object clients or object servers, depending upon wheth- 
er they are sending requests to other objects or replying 
to requests from clients. 

In a distributed object environment, requests and 
replies are made through an Object Request Broker 
(ORB) that is aware of the locations and status of the 
objects. One architecture which is suitable for imple- 
menting such an ORB is provided by the Common Ob- 
ject Request Broker Architecture (CORBA) specifica- 
tion. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distrib- 
uted computing environment world in terms of objects 
in a distributed client-server environment, where server 
objects are capable of providing services to clients re- 
questing the service. In the following discussion, the 
terms "object" and "distributed object" will be used in- 
terchangeably, as the following invention is directed to 
both types. 

In a preferred embodiment of the present inventbn, 
distributed objects are located on one or more comput- 
ers linked together by a network. The network may take 
any suitable form. By way of example a representative 
network arrangement 10 is illustrated in Fig. 1 . The net- 
work arrangement 1 0 includes a first computer 1 2 which 
is coupled to a transmission line 1 4. The network 1 0 fur- 



ther includes a server, router or the like 16 in addition to 
other computers 18, 20, and 22 such that data and in- 
structions can be passed among the networked comput- 
ers. The design, construction and implementation of 
s computer networks will be familiar to those of skill in the 
art. 

A representative computer 30 suitable for use as 
computers 12, 18, 20, and/or 22 of Fig. 1 is illustrated 
schematically in Fig. 2. Computer 30 includes a central 

10 processing unit (CPU) 32 which is coupled bidirection- 
ally with random access memory (RAM) 34 and unidi- 
rectionally with read only memory (ROM) 36. Typically, 
RAM 34 is used as a "scratch pad" memory and includes 
programming instructions and data, including distribut- 
es ed objects and their associated code and state, for proc- 
esses currently operating on CPU 32. Note that tran- 
sient state is often stored in transient memory such as 
RAM 34. ROM 36 typically includes basic operating in- 
structions, data and objects used by the computer to 

20 perform its functions. In addition, a mass storage device 
38, such as a hard disk, CD ROM, magneto-optical (flop- 
tical) drive, tape drive or the like, is coupled bidirection- 
ally with CPU 32. Mass storage device 38 generally in- 
cludes additional programming instructions, data and 

& objects that typically are not in active use by the CPU, 
although the address space may be accessed by the 
CPU, e.g., for virtual memory or the like. Note that per- 
sistent state is often stored in persistent memory such 
as storage device 38. Each of the above described com- 

30 puters optionally include input/output sources 40 that 
typically include input media such as a keyboard, pointer 
devices (e.g., a mouse or stylus) and/or network con- 
nections. Additional mass storage devices (not shown) 
may also be connected to CPU 32 through a network 

35 connection. It will be appreciated by those skilled in the 
art that the above described hardware and software el- 
ements, as well as networking devices, are of standard 
design and construction, and will be well familiar to 
those skilled in the art. 

40 Returning to the discussion of the client and server, 
one of the underpinnings of distributed object environ- 
ments is the interaction between the client, which is de- 
fined herein as an entity requesting a service, and a 
server, which is typically an object providing the service. 

45 For example, different scenarios include the client and 
server within the same process, in different processes 
on the same host computer, and on different processes 
running on different host computers. This clientobject 
interaction can be discussed in terms of a client-server 

50 model. By way of example, a client may be in a process 
running on a network computer, such as computer 12, 
which requests services from a server object in a differ- 
ent process running on a remote computer 18. 

As will be appreciated by those of skill in the art, the 

55 entities which can be a client include, but are not limited 
to, a process running on a host computer, hereinafter 
referred to as a client process and client host respec- 
tively, and an object, hereinafter referred to as a client 
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object. Therefore, a client is an entity requesting a serv- 
ice, regardless of the type of entity. For the sake of clar- 
ity, the object providing the service is hereinafter re- 
ferred to interchangeably as a target object or a server 
object. Thus in the following description, when a client 
invokes a target object, the client may be any entity such 
as a client process or a client object. 

Elaborating further on the terminology of client- 
server interactions, a client will "call" a target object to 
"invoke" a "method" that is executed by the target object. 
Note that while "call" and "invoke" can carry slightly dif- 
ferent meanings, herein the two terms are used inter- 
changeably and their meanings will be understood from 
the context of the discussion herein. As is well known to 
those of skill in the art, a method is a procedure con- 
tained within an object which is made available to other 
entities, i.e. clients, for the purpose of requesting serv- 
ices of that object. Thus the object performing the serv- 
ice for the client is the server, hence the phrase client- 
server. In calling a method, the client may also pass 
those arguments, also referred to as parameters, nec- 
essary for the target object to perform the requested 
method. Please note that the previous term "method" is 
a term of the art of object oriented programming and dif- 
fers from the term "method" classically used in drafting 
patent applications. In the following discussion, the Ap- 
plicant believes that it is made clear (either by context 
or by a hint from the Applicant) which meaning for the 
term "method" is used- 
Referring next to Figs. 3a - 3c, a few possible enu- 
merations of a client-server model that are very repre- 
sentative of a distributed object environment will be dis- 
cussed. As is always the case, the client-server model 
will have a client entity and a target object which is the 
server entity. One such arrangement for the fol towing 
client-server models includes computers such as com- 
puter 30 of Fig. 2 interconnected over a network 1 4 as 
shown in Fig. 1 . 

Turning first to Fig. 3a, a client-server model 300 
termed "host-to-host" is shown wherein client 302 and 
target object 304 exist on different host computers within 
a distributed object operating environment 301 . Ihe cli- 
ent 302 exists in a client process 306 which is running 
on a client host computer 308. Client 302 uses a first 
surrogate object 31 0 which holds [e.g. it has a first indi- 
rection 312 to) an object reference 314. In tum, object 
reference 314 provides a second indirection 316 to the 
target object 304. As used herein, an indirection to an 
object is simply enough information to locate the object, 
although perhaps not by way of direct interaction with 
the object. In the case of Fig. 3a, the first indirection 31 2 
is typically just a direct pointer to the object reference, 
while the second indirection 316 is often more elaborate. 
Indirections such as indirection 316 will be discussed in 
more detail later with respect to Figs. 5a and 5b. Addi- 
tionally, there may be other surrogate objects present in 
the client process 306, such as second surrogate object 
311, which may also hold the object reference 314. In 



some cases surrogate objects 310 and 311 may be tra- 
ditional programming language objects. However some 
distributed object operating environments do not include 
surrogate objects. In these cases, the client 302 will uti- 
s lize the object reference 31 4 without a surrogate object. 
Similar to the client 302, the target object 304 of Fig. 
3a can exist in a server process 318 which is running 
on a server host 320. Other entities may be resident on 
both the server host 308 and the client host 320. These 

10 include but are not limited to additional processes and/ 
or objects running under the client process, the server 
process, and/or the additional processes. Two suitable 
processes are daemon_1 process 317 running on client 
host 308 and daemon_2 process 321 running on server 

15 host 320. Daemon processes typically run in the back- 
ground and are well known to those skilled in the art. 

As Fig. 3a illustrates, in the host-to-host case, client 
302 must pass its call to the target object 304 through 
several "layers", i.e. complexities not directly related to 

20 the service requested of the target object. In the host- 
to-host example, a network connection must be estab- 
lished between the client 302 and the target object 304. 
Because of the different layers such as the client and 
server hosts 308 and 320 and the client and server proe- 
ms ess 306 and 318, the client-server network connection 
can not be established directly. Rather, the client proc- 
ess 306 must interpret the call, and pass this on to the 
surrogate object 31 0 which may use the ORB to first find 
the server host 320 and then identify the server process 

30 318 and target object 304. Furthermore, as this data is 
being communicated over the network, this data must 
be marshaled (i.e. formatted according to the network 
communications protocol so as to prepare it for trans- 
mission over the network), sent, received, and finally un- 

35 marshaled. Thus, host-to-host is a complicated case of 
the client-server interaction. Accordingly, the additional 
layers and resultant steps make the host-to-host client- 
server interaction often the most expensive possible in- 
teraction in terms of system resource utilization. 

*o Fig. 3b shows a "process-to-process" client-server 
model in which the client 302 and the target object 304 
share the same host computer, a client/server host 322. 
However, client 302 and target object 304 reside within 
different processes. Similar to Fig. 3a, the client 302 ex- 

45 jsts in a client process 306 which is running on the client/ 
server host 322. The client 302 uses a first surrogate 
object 31 0 which holds (eg, it has a first indirection 31 2 
to) an object reference 31 4. In tum, object reference 31 4 
provides a second indirection 31 6 to the target object 

so 304. Target object 304 exists within in a server process 
318 which is running on the client/server host 322. Akin 
to the ■host-to-host" case, further entities such as proc- 
esses and/or objects may be resident on client/server 
host 322. For example, there may be other surrogate 

55 objects present in the client process 306, such as a sec- 
ond surrogate object 311, which may also hold the ob- 
ject reference 314. However some distributed object op- 
erating environments do not include surrogate objects. 
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In these cases, the client 302 will utilize the object ref- 
erence 31 4 without a surrogate object. I n any event, the 
process-to-process interaction may be significantly bet- 
ter than the host-to-host interaction. This is, in part, be- 
cause the network communication steps are unneces- 
sary. 

Fig. 3c shows a client-server model in which both 
client 302 and target object 304 reside within the same 
process, the client/server process 324. Once again, the 
client 302 uses a first surrogate object 310 which holds 
{e.g. it has a first indirection 31 2 to) an object reference 
314. In turn, object reference 314 provides a second in- 
direction 316 to the target object 304. In this case the 
second indirection 316 may just be a pointer to shared 
memory. This situation is perhaps the best of all three 
described cases. No network communications is neces- 
sary, and since both objects are under one process, they 
coexist in memory allocated to the client/server process 
324. In the situation of Fig. 3c, other entities such as 
objects may be resident in client/server process 324. 
For example, there may be other surrogate objects 
present in the client process 306, such as a second sur- 
rogate object 311 , which may also hold the object refer- 
ence 314. However some distributed object operating 
environments do not include surrogate objects. In these 
cases, the client 302 will utilize the object reference 31 4 
without a surrogate object. 

Two other typical client-server scenarios which are 
not shown in the above described Figs, will now be dis- 
cussed briefly. The first scenario involves the embodi- 
ments wherein the client is an object. As will be appre- 
ciated by those of skill in the art, the issues which arise 
are very similar (often identical) whether the client is an 
object or some other entity requesting service. The other 
scenario is one wherein the client object and the target 
object are the self-same object. This may occur when 
an object makes a recursive call upon itself. While the 
recursive call may appear unusual, this client-server in- 
teraction is a fairly common and powerful tool and may 
be dealt with in a manner similar (or perhaps identical) 
to the case wherein a client object and a target object 
are unique but exist in the same process. 

Fig. 4a shows the progression of a persistent object 
401 through three different states. The first transition 
400 brings the persistent object 401 from a previous 
state into state 1 . State 1 of object 401 includes both 
transient state 402 and persistent state 404. Transition 
406 brings the persistent object 401 from state 1 into 
state 2. Similar to state 1 , state 2 of object 401 has both 
transient state 408 and persistent state 410. Finally, 
transition 41 2 brings the persistent object 401 from state 
2 into state 3. Once again, state 3 of object 401 has both 
transient state 41 4 and persistent state 416. For the per- 
sistent object 401 , the transitions 400, 406, and 41 2 can 
be any operation which changes the state of the object 
401 , including the termination of a process under which 
the object exists. Because the persistent object includes 
persistent state at each stage, it has the capacity to 



bridge from process to process and maintain itself for 
long periods of time. 

In contrast, Fig. 4b show the progression of a tran- 
sient object 417 through three different states. The first 
5 transition 41 8 brings the transient object 41 7 from a pre- 
vious state into a state A. State A of transient object 41 7 
includes transient state 420 but does not include any 
persistent state. Transition 422 brings the transient ob- 
ject 417 from state A into a state B. Similar to state A, 
10 state B of transient object 417 has transient state 424 
and does not have any persistent state. Finally, transi- 
tion 426 brings the transient object 41 7 from state B into 
a state C. Once again, state C of transient object 417 
has transient state 428 and does not have any persistent 
is state. For the transient object 417, the transitions 418, 
422, 426 can be any operation which changes the state 
of the transient object 41 7, with the exception of opera- 
tions which include cessation of the process under 
which the transient object 41 7 exists. Because the fran- 
co sient object 41 7 does not include persistent memory, it 
cannot bridge across processes. Therefore transient 
objects exist in one and only one process and cease to 
exist when the process ceases. Additionally, note that a 
process' location and address cannot change, therefore 
25 a transient object's location and address cannot 
change. 

From the above discussion of the client-server mod- 
el and the relationship to transient and persistent ob- 
jects, it should be apparent that frameworks for handling 

30 client-server interactions efficiently and flexibly are pre- 
ferred. One framework which provides apparatus and 
data structures will now be discussed. 

In order to facilitate the aforementioned client-serv- 
er interactions, distributed object operating systems (in- 

35 eluding the distributed architecture specified by COR- 
BA) typically incorporate an object termed an "object ref- 
erence." Object references serve both to locate and to 
identify the target objects of individual operation re- 
quests, as well as to provide general parameters of op- 

40 e ration. Because of the differences in dealing with the 
different kinds of objects, there are no teachings in the 
prior art which incorporate both transient and persistent 
objects under the same framework. However, the teach- 
ing of the present invention includes a framework for use 

45 within a distributed object operating environment which 
integrates both transient and persistent objects. One 
embodiment incorporating transient object references 
and persistent object references will be discussed later 
in more detail. 

50 As object references direct a client to their corre- 
sponding target object, there is another meaningful way 
of looking at the adjectives "transient" and "persistent" 
as used to modify the term "object reference." Persistent 
object references are an indirection (they locate and 

55 identify) to a distributed object which has continuity of 
identity. Therefore, the indirection of a persistent object 
reference is a persistent indirection as it is always valid 
(unless the identity of the persistent object is destroyed). 
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In contrast, transient object references are a direction 
to a distributed object which has no continuity of identity. 
Therefore, the direction of a transient object reference 
is a transient direction. 

In addition to transient and persistent object refer- 
ences there are two additional kinds of object references 
which should be mentioned. The first is a "null' object 
reference and the second is an 'invalid - object refer- 
ence. Similar to transient and persistent object referenc- 
es, null object references and invalid object references 
correspond to null and invalid objects. A null object may 
be an object which does not have an interface, or is in 
a state in which it will not serve clients. In preferred em- 
bodiments the null object reference is supported and 
therefore may be coded. An invalid object is typically a 
nonexistent or ill-formed object and is usually not sup- 
ported. Therefore a invalid object may typically not be 
coded. 

Fig. 5a shows a pictorial illustration of a data struc- 
ture for a transient object reference 500 in accordance 
with one embodiment of the present invention. The ob- 
ject reference 500 includes an kind field 501, a set of 
endpoint addresses 502, an incarnation number 504, 
and an object key 506. In preferred embodiments, kind 
field 501 is a data element which represents the object 
kind to which object reference 500 indirects. In other em- 
bodiments, the kind field 501 is not included in the object 
reference 500 and the object kind is determined by the 
distinguishing features of the data structure of the object 
reference 500. That is, the object kind to wh ich an object 
reference indirects can be determined uniquely by the 
data structure of the object reference. 

Continuing the discussion of Fig. 5a, the set of end- 
point addresses 502 includes addressing information 
necessary for a client to locate the server host and serv- 
er process in which the target object may exist. This in- 
formation may include elements such as the server host 
network address, the server process network port 
number, and/or the memory location of the target object. 
Furthermore, the set of endpoint addresses may include 
a plurality of addresses, each of which may be valid. The 
set of endpoint addresses may include a variable or a 
fixed length data element. Suitable lengths for a fixed 
length data element are in the range of about 1-128 
bytes, while lengths in the range of about 24 - 96 bytes 
are preferred, with a length of about 64 bytes being more 
preferred. By way of example, if the network protocol is 
the well known transmission control protocol/Internet 
protocol (TCP/IP), then one address in the set of ad- 
dressing information 502 may include a six byte data 
element wherein the first four bytes are the TCP/IP serv- 
er host network address, in network order, and the other 
two bytes are the TCP/IP server process network port 
number, also in network order. 

Another element of the object reference 500 of Fig. 
5a, the incarnation number 504, is an identifier which 
prevents misdelivery of ORB requests to the wrong des- 
tination in the event of address reuse. In other words, 



even with the set of addressing information, which pin- 
points the server host address and the server process 
identification, it still is possible that the server process 
is not uniquely identified. As discussed below, the incar- 
5 nation number of the present invention overcomes po- 
tential ORB misdeliveries. 

While a misdelivery may seem impossible at first 
glance, one must carefully consider how transient ob- 
jects and their host server processes are managed. 

10 Transient objects do not exist from process to process, 
but rather cease when their server process ceases. But, 
as those of skill in the art will understand, a running com- 
puter creates and deletes computer processes con- 
stantly, each of these processes having a specific net- 

is work address. Therefore rt is certain that one process 
may cease, thereby ceasing all the unique transient ob- 
jects which exist within it and also freeing up a network 
address. This network address may be reused as there 
are typically only a finite quantity of process network ad- 

20 dresses available (32,768 or 32K is a typical number). 
Thus a request for a transient object which has ceased 
may be misdirected by the ORB if some other distin- 
guishing identification is not provided. 

As the ORB is responsible for interpreting the incar- 

25 nation number 504, the ORB, and more specifically the 
object adapter (OA), is typically responsible for the as- 
signing of the incarnation number 504. This number can 
be arbitrary as long as it is distinguishable by the ORB. 
Various embodiments of the incarnation n umber 504 are 

30 contemplated. For example, assigning the incarnation 
number 504 some monotonicaily increasing value, such 
as a timestamp, allows the ORB to distinguish between 
different processes which exist inconcurrently but hap- 
pen to receive the same address. In other cases, rt may 

35 be desirable to have two or more processes which are 
indistinguishable. In this case, identical incarnation 
numbers could intentionally be assigned. Still further sit- 
uations may arise when it is desirable to have a prede- 
termined number such as zero be assigned to the incar- 

40 nation number 504. In any event, the incarnation 
number 504 may include a data element of fixed or var- 
iable length, depending upon the predetermined proto- 
col. Suitable lengths for a fixed length data element are 
in the range of about 1-16 bytes, with lengths in the 

45 range of about 2-6 bytes being preferred and a length 
of about 4 bytes being more preferred. 

As will be appreciated by those skilled in the art, the 
incarnation number, either as described in the above 
embodiment or in other embodiments, enables a distrib- 

50 uted object operating environment to flawlessly distin- 
guish transient objects. The incarnation number is novel 
to the present invention and allows the use of persistent 
and transient objects within a distributed object environ- 
ment. 

55 The last listed element of the transient object refer- 
ence 500 of Fig. 5a is the object key 506. In one embod- 
iment object key 506 serves to distinguish between ob- 
jects within the server process. Depending upon the pre- 
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determined protocol, the object key 506 may include a 
data element of fixed or variable length. Suitable lengths 
for a fixed length data element are in the range of about 
1-16 bytes, with lengths in the range of about 4-8 bytes 
being preferred and a length of about 6 bytes being more 
preferred. 

Fig. 5b shows a pictorial illustration of a persistent 
object reference 510 according to one embodiment of 
the present invention. The persistent object reference 
51 0 is an object which points to a persistent server ob- 
ject, and includes a kind field 511, a host name 512, a 
locator identification number (locator id) 514, an object 
key 516, and a sub-object identifier 518. As shown, the 
persistent object reference may also include an optional 
location hint 520. As discussed above with respect to 
Fig. 5a, kind field 511 is a data element which represents 
the object kind to which object reference 510 indirects. 
The host name 512 indicates a host computer which has 
a locator service (which is an entity such as a locator 
process or a locator object) responsible for maintaining 
the locations of target objects. For example, the host 
name 512 may include a network address. In preferred 
embodiments the host computer indicated by host name 
512 has the target object resident therein. 

Referring next to the third listed element of the per- 
sistent object reference 51 0 of Fig. 5b, the locator id 51 4 
uniquely identifies the locator service on the host which 
is defined by the host name. In one embodiment the lo- 
cator id includes a fixed length data element. By way of 
example, one suitable embodiment of the locator id 514 
is a remote procedure call (RPC) program number for 
the locator. Those of skill in the art will be familiar with 
RPC protocols and the generation of RPC program 
numbers. In general, the RPC service will maintain a 
correspondence between a constant RPC program 
number and the desired server process addressing in- 
formation. That is, the RPC service is updated whenever 
the server process addressing information is changed. 
Thus the distributed object system need not update the 
persistent object reference. In this case, the locator id 
514 may be a fixed length data element with a length of 
4 bytes. Turning next to the fourth element of Fig. 5b, in 
one embodiment object key 516 uniquely defines the 
target object with respect to the locator. Hence the lo- 
cator uses the object key 516 to determine which de- 
sired target object is being requested. 

The combined data elements 512-516 constitute 
one example of what is known in the art as an "indirec- 
tion." An "indirection' is a set of information, a pointer, 
etc., which directs the client entity to a source (such as 
a locator object) which can direct the client entity to the 
object. By way of a descriptive analogy, if a client re- 
quested geographical directions, an indirection would 
point the client to the location of a current map, or per- 
haps provide the client with a phone number of a geo- 
graphically astute individual. The idea of using an indi- 
rection (rather than direct addressing) is useful for per- 
sistent objects as these are mobile both from process 



to process and host computer to host computer 

With continued reference to Fig. 5b, the sub-object 
identifier 518 is a data element typically used only by 
the target object to manage finer grained objects. By 
5 way of analogy, a spread sheet may be an object, with 
the cells of the spread sheet being sub-objects. The 
granularity of objects, sub-objects and methods and ap- 
paratus for managing sub-objects are described in more 
detail in copending U.S. Patent Application Serial 
10 Number (Attorney Docket No. P/717SUN1P023) enti- 
tled "METHODS AND APPARATUS FOR MANAGING 
COLLECTIONS OF OBJECTS", by Vanderbilt et. al., 
which is incorporated herein by reference in its entirety. 
Another element optionally included in the persistent ob- 
is ject reference 510 is the location hint 520. The location 
hint 520 is an optional data element which provides de- 
tails regarding the last known location of the target ob- 
ject. The location hint 520 may also include an expiration 
timestamp. By way of explanation, the target object may 
have been called previously, thus the addressing infor- 
mation for the target object was retrieved at an earlier 
time. By using this location hint 520, the distributed op- 
erating system can avoid making the call to the locator. 
Of course, if the location hint 520 has expired or is not 
present, then the locator must be queried anyway. 

The embodiment of the present invention described 
above with respect to Figs. 5a and 5b serves to wholly 
integrate the different kinds of object references into one 
distributed operating environment framework. As de- 
scribed, the distributed object environment can distin- 
guish between the two primary kinds of object referenc- 
es and still maintain the advantages accorded to each 
kind. 

Further integration occurs by utilization of the data 
elements provided by the present invention. For exam- 
ple, the object key in both transient and persistent object 
references may be used for transporting an object ref- 
erence formatted according to a first protocol of a first 
distributed system into a second distributed system uti- 
lizing a second protocol. This may be done by formatting 
a second object reference according to the second pro- 
tocol and storing this in a variable length object key of 
the first object reference. Upon receiving the object ref- 
erence, the second distributed system can strip out the 
object key and generate an object reference for the tar- 
get object which is in the proper format for the second 
distributed system. Thus both transient and persistent 
object references can transfer across protocols by an 
identical mechanism - the object key. 

Still further evidence of the wholly integrated frame- 
work which the present invention provides can be found 
in considering the location hint of the persistent object 
reference data structure. As will be apparent, a suitable 
embodiment for the location hint may include a set of 
addressing information, an incarnation number, and an 
expiration date. In the case where the location hint is 
available, current, and valid, the persistent object refer- 
ence indirects to its persistent object by the exact same 
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mechanism that a transient object reference directs to 
its transient object. Not only is this combination effective 
for integrating the two kinds of object references, it lays 
the framework for a novel and cost effective method 
(with respect to system resource utilization) for calling 
persistent target objects, which method is: making calls 
to persistent distributed objects directly rather than 
through the use of a locator. 

While the disclosed embodiments of transient and 
persistent object references provide a few preferred 
frameworks for implementing the data structure aspect 
of the present invention, there are many other suitable 
embodiments. For example, in some embodiments the 
distributed operating system may update each and eve- 
ry object reference when a persistent object moves its 
location. Thus both persistent and transient object ref- 
erences may have direct addressing information, rather 
than the indirection described in the embodiment of the 
persistent object reference 510 of Fig. 5b. In a further 
example, some embodiments may eliminate direct ad- 
dressing completely, depending only on an indirection. 
In this case, the transient object reference may appear 
in a form akin to the persistent object reference 510. Still 
further embodiments would incorporate features re- 
quired by specific network communications protocols to 
enable operation under their particular framework. 

As will be apparent from the foregoing discussion, 
a distributed operating system which utilizes the afore- 
mentioned structures for objects, which include tran- 
sient and persistent objects, and transient and persist- 
ent object references, will have many advantages over 
the prior art. These advantages will be made clearer in 
the following discussion of client-server interactions 
which utilize method aspects of the present invention. 

Turning now to Fig. 6, a method 600 for implement- 
ing the client-server interaction in accordance with one 
embodiment of the present invention will be described. 
The client-server interaction begins in a step 602 when 
the client invokes the server object (also referred to as 
the target object). The client may be any suitable entity 
such as a client process or a client object. In a next step 
604, the client acquires addressing information regard- 
ing the server object. For example, the addressing in- 
formation acquired may include data such as described 
in the previous discussion of transient and persistent ob- 
ject references. It should be appreciated that this ad- 
dressing information may include a plurality of address- 
es from which one specific address is chosen. One cri- 
terion for choosing the address is to enable the fastest 
mode of transport between the client and the server. An- 
other common criterion for choosing the address is se- 
curity. Also, acquiring this addressing information may 
include various steps due to the fact that the information 
may be located at different sources. 

Once the addressing information is acquired in step 
604, the client, in a step 606, evaluates the addressing 
information to choose a specific address. In step 606 
the client may select an address based on different ra- 



tionale, including goals such as transport speed be- 
tween client and server, load sharing, security, and/or 
concerns regarding the integrity of the addressing infor- 
mation. A more detailed illustration of one embodiment 
s of the substeps of step 606 is discussed below with ref- 
erence to Fig. 8. 

Continuing on through method 600 of Fig. 6, the cli- 
ent, in a step 608, sends the request to the address cho- 
sen in step 606. If the address is a remote address, step 
608 may include the steps of marshaling the chosen ad- 
dress together with the method and arguments, estab- 
lishing a network connection with the remote target ob- 
ject, and then making a remote call to the target object. 
As used herein, to "marshal" data is to format the data 
in accordance with a predetermined network communi- 
cation protocol in preparation for network transmittal. In 
a step 610, it is determined if the client expects a re- 
sponse, and, if so, process control is passed to a step 
612 wherein the client receives the response from the 
target object. Similar to step 60S, if the target object is 
remote, then the client may 'unmarshaP the response 
from target object, Le. the data is translated from a pre- 
determined network communication protocol into a for- 
mat meaningful to the client. After receiving the re- 
sponse, or if no response is expected, control proceeds 
to a step 614 upon which the client-server interaction of 
Fig. 6 is complete. 

Referring now to Fig. 7, a more detailed description 
of step 604 in accordance with one method aspect of 
the present invention will be described. As will be ap- 
preciated by those of skill in the art, the method of Fig. 
7 is generally for use in a distributed object system uti- 
lizing the object references of Fig. 5a and 5b or similar 
object references. However, as will be apparent, the 
scope of the present invention includes other embodi- 
ments of step 604 which are more suitable for additional 
embodiments of object references. 

The flow chart of Fig. 7 begins in a step 702 when 
control is passed to step 604 of Fig. 6. The initial sub- 
stantive step of Fig. 7, step 704, determines if the object 
kind is transient. As discussed above in reference to 
Figs. 5a and 5b, the object kind determination can be 
accomplished by various methods such as examining 
the internal name. In the case where the object kind is 
transient, control branches to a step 706 where the ad- 
dressing information is returned directly from the object 
reference. This is possible because a transient object 
reference in accordance with Fig. 5a has direct address- 
ing information, as opposed to an indirection. Once the 
addressing information is returned in step 706, control 
is passed to a step 708 where the acquire addressing 
information step 604 is complete. 

Following down the other branch of step 704, if the 
object kind is not transient, control is passed to a step 
710, where it is determined if the object kind is persist- 
ent. If the object kind is not persistent (the object is null 
or invalid), control is passed to a step 712 wherein an 
error message is generated and step 604 is complete. 
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As should be apparent, if the object is neither transient 
nor persistent, it is improper to send a request to the 
target object (as it is either null or invalid) and thus an 
error message is appropriate. 

On the other hand, if in step 710 it is determined s 
that the object kind is persistent, then in a step 714 a 
memory cache-1 is checked to see if the target object 
addressing information is resident therein. If so, control 
proceeds to a step 720 where the addressing informa- 
tion is returned directly from cache-1 and then on to step 10 
708 where step 604 (which acquired addressing infor- 
mation) is complete. The cache memory may be any 
suitable memory such as local RAM 38 described in ref- 
erence to Fig. 2. Storing and retrieving the addressing 
information in memory cache-1 allows for direct and is 
speedy access to this information. 

If the addressing information is not resident in 
cache-1 , control proceeds to a step 716 were the client 
obtains the addressing information. Typically the ad- 
dressing information is obtained in step 716 by means 20 
of an indirection utilizing a locator service as described 
previously with reference to Figs. 5a and 5b. One em- 
bodiment of step 716 will be described in more detail 
below with respect to Fig. 9. After the addressing infor- 
mation is obtained in step 71 6 it is stored in cache-1 in 2s 
a step 718, thereby perpetuating the efficiency of this 
method. Additionally, another mechanism for increasing 
the addressing information available in cache-1 will be 
described below in reference to Fig. 11 . Then, in a step 
720, the addressing information is returned from cache- 30 
1 and control is passed to a step 708 where the acquire 
addressing information step 604 is complete. 

One embodiment of the choose address step 606 
of Fig. 6 will now be described in further detail with re- 
spect to Fig. 8. This embodiment serves primarily to se- 35 
lect the addressing information which will provide the 
fastest mode of transport between the client and the 
server. The three different modes of transport described 
herein are (in descending order of transport speed) lo- 
cal, shared memory, and remote transport. Local trans- 40 
port occurs within the same process and is performed 
by copying data within the same address space. Shared 
memory transport (may also be called "same host") is 
performed using the host operating system inter-proc- 
ess communication procedures. Remote transport is 45 
performed using networking facilities. Each of these 
may vary depending upon factors such as the operating 
system and the network communication protocol. The 
design and implementation of local, shared, and remote 
transport will be familiar to those skilled in the art. 

The flow chart of Fig. 8 begins in a step 802 when 
control is passed to step 606 of Fig. 6. Then, in a step 
804, it is determined if the target object is running in the 
client process. If so, then in a step 806 the local address 
and local transport are selected to connect the client and 
server. On the other hand, if the target object does not 
run in the client process, then in a step B10 it is deter- 
mined if the server object is running on the same host 



as the client and if shared memory addressing informa- 
tion is available. If so, then in a step 8 1 2 shared memory 
addressing and shared memory transport are selected 
to connect the client and server. Otherwise, if the target 
object is resident neither in the client process nor in the 
client host, a step 814 selects the remote address and 
remote transport to connect the client and server. In any 
event, after the addressing has been selected, control 
is passed to a step 808 wherein step 606 of Fig. 6 is 
complete. 

Referring next to Fig. 9, one embodiment of step 
716 of Fig. 7 is described in more detail. The method of 
Fig. 9 begins in a step 902 when the get addressing step 
716 receives control. Next, in a step 904, the transient 
object reference for an ORB daemon process is ob- 
tained by way of the locator id and the host name. In 
one embodiment, an ORB daemon process is resident 
on each computer system of the distributed object en- 
vironment. The ORB daemon specifically found in step 
904 is a process running in the background on the server 
host computer, under which a locator object is active. 
Daemon processes are well know to those of skill in the 
art. Next in a step 906 the client calls the locator object 
to invoke a look-up method, passing arguments includ- 
ing the object key for the target object. In response, the 
ORB daemon will return direct addressing information 
for the target object. In preferred embodiments the dae- 
mon process will additionally verify the state of the serv- 
er process, starting the process if necessary. One pre- 
ferred embodiment of server process startup can be 
found in Vanderbilt et. al.'s copending U.S. Patent Ap- 
plication Serial Number (Attorney Docket No. 
P747/SUN1P030) entitled "METHODS AND APPARA- 
TUS FOR MANAGING COMPUTER PROCESSES", 
which is incorporated herein by reference in its entirety. 
After the direct addressing information is received, con- 
trol is passed to a step 908 wherein step 716 of Fig. 7 
is complete. 

Turning next to Fig. 10, one embodiment of step 904 
of Fig. 9 is described in more detail. The method of Fig. 
10 begins in a step 1002 when the get transient object 
reference for ORB daemon step 904 receives control. 
In a step 1004, it is determined if the transient object 
reference for the ORB daemon is resident in a memory 
cache-2. If so, control branches to a step 1012 where 
the transient object reference for the ORB daemon is 
returned directly from cache-2. After the transient object 
reference is returned, control is passed to a step 1014 
wherein step 904 of Fig. 9 is complete. 

If the transient object reference for the ORB dae- 
mon is not resident in cache-2, the control branches to 
a step 1006, wherein the client calls the remote proce- 
dure call (RPC) binder on the server host, passing the 
locator id and the incarnation number as arguments to 
the call. In response, the RPC binder returns addressing 
information and in a step 1008, the client constructs the 
transient object reference utilizing the returned ORB 
daemon addressing information. Implementation and 
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construction of the RPC binder are well known to those 
skilled in the art. Once the transient object reference has 
been constructed, the client stores it in cache-2 in a step 
1 01 0, thereby perpetuating the efficiency of this method. 
Then control is passed to a step 1012 where the tran- 
sient object reference for the ORB daemon is returned 
directly from cache-2. After the transient object refer- 
ence is returned, control is passed to a step 101 4 where- 
in step 904 of Fig. 9 is complete. 

One method for increasing the addressing informa- 
tion available in cache-1 will be described now with ref- 
erence to Fig. 11 . By way of background, an object ref- 
erence for a persistent object may have an optional lo- 
cation hint (as described jn reference to Fig. 5b and else- 
where). The location hint includes direct addressing in- 
formation for a target object. Thus each location hint has 
the addressing information step 714 of Fig. 7 is looking 
for in cache-1 . Furthermore, as will be appreciated by 
those skilled in the art, object references may be re- 
ceived by a host computer either through an object call 
or in response to an object call. Thus there is the poten- 
tial to increase the addressing information every time an 
object reference is received. 

In the method of Fig. 11, a first step 1100 unmar- 
shals an object reference which has been received for 
any reason such as the two mentioned in the preceding 
paragraph. Then, in a step 1102, it is determined if the 
object reference has a location hint. If so, in a step 1 1 04, 
the addressing information and an expiration date (if 
present) from the location hint is stored into cache-1 . If 
there is no location hint, or subsequent to updating the 
cache-1, the method of Fig. 11 is done in a step 1106 
and the object reference can be used for its originally 
intended purpose. 

In another method aspect of the present invention, 
one closely related to the method of Fig. 11 , the separate 
computers of the distributed object operating environ- 
ment work together to share addressing information. 
Therefore, when one computer uses a locator service 
to obtain addressing information about a target object, 
this computer may in turn distribute this information 
along to the other computers of the distributed object 
operating environment. One suitable way to pass this 
information would be by way of an object reference. 
Then each computer would store this addressing infor- 
mation along with an expiration date into its cache-1 
memory. 

One further advantage of the present invention can 
now be discussed. As will be appreciated by those of 
skill in the art, one model (useful for the present discus- 
sion) divides the ORB into three different abstract levels, 
defined herein as the Application Level ORB, the Trans- 
port Level ORB, and the Communication Level ORB. 
Components representative of the lower Communica- 
tion Level ORB would include the activities of the 
shared, local, and remote addressing and transport dis- 
cussed above with respect to Fig. 8. Components rep- 
resentative of the upper Application Level ORB would 



include the initial client call to a server, wherein the lo- 
cation and object kind of the server was opaque to the 
client. The middle level, the Transport Level ORB, is the 
only portion of the ORB which must to be concerned with 
s the kind of the server object. Thus the present invention 
accomplishes the task of integrating transient and per- 
sistent objects within a distributed object environment 
without introducing an undue burden throughout the 
ORB, thereby ensuring the efficiency of the distributed 
io object environment. 

Although only a few embodiments of the present in- 
vention have been described, it should be understood 
that the present invention may be embodied in many 
other specific forms without departing from the spirit or 
is scope of the invention. The client-server models dis- 
cussed with reference to Figs. 3a - 3b are only samples 
and in no way should be construed as limiting. By way 
of example, the "host-to-nost" model could be extrapo- 
lated to include multiple target objects. That is, the first 
target object 304 could simply be an object reference 
which indirects to another target object, perhaps in an- 
other distributed object environment. Or, the first target 
object could perform a portion of the requested service 
and then make its own call to a second target object be- 
fore responding to the first client 302. As will be appre- 
ciated, the possible enumerations take on many embod- 
iments, all of which fall within the scope of the present 
invention. 

Still further, the data structures of Fig. 5a and 5b 
may be varied greatly and yet fall within the scope of the 
present invention. As a first example, data structures for 
both transient and persistent object references could be 
embodied without the kind field. Still further examples 
can be found by contemplating the multiplicity of net- 
work communication protocols, operating systems, and 
applications programs. Each of these may require a 
specific arrangement of the described data structures. 
Construction and implementation of each of these nu- 
merous embodiments will be apparent to those skilled 
in the art and, accordingly, fall within the scope of the 
present invention. 

As will be appreciated by those skilled in the art of 
distributed object systems, the underlying ideas behind 
the described methods of handling transient and per- 
sistent objects can be implemented in a wide variety of 
alternative embodiments, of which there far too many to 
discuss in detail. However, since the underlying philos- 
ophy has been described, varbus alternatives will be 
obvious to those skilled in the art. By way of example, 
the method of selecting a transport mode, one embod- 
iment which was described with respect to Fig. 8, may 
have many variations. The selection criterion could em- 
phasize a load sharing desire, thus a remote address 
may be the best address under this criterion. From an- 
other aspect, there may be different forms of transport 
not described. However, if other forms of transport are 
available, those of skill in the art will understand how to 
apply the teaching of the present invention to utilize 
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these other modes of transport. 

Therefore, the present examples are to be consid- 
ered as illustrative and not restrictive, and the invention 
is not to be limited to the details given herein, but may 
be modified within the scope of the appended claims. s 

Claims 

1 . An object for use as an object reference for a tran- 10 
sient object, said transient object intended to reside 

in a server computer process executing on a server 
computer system in a distributed object operating 
environment contemplating a plurality of distributed 
transient objects, said object having a data struc- is 
ture comprising: 

a set of endpoint addresses corresponding to 
said server computer system; 

20 

an incarnation number corresponding to said 
server computer process; and 

an object key corresponding to said transient 
server object, 25 

such that said set of endpoint addresses, said 
incarnation number, and said object key 
uniquely identify and locate said transient serv- 
er object. 30 

2. A object as described in claim 1 wherein said data 
structure further includes a kind field indicating that 
said transient object kind is transient. 

35 

3. An object as described in claim 1 wherein said set 
of endpoint addresses is a data element of variable 
length. 

4. An object as described in claim 1 wherein said set 40 
of endpoint addresses is a data element of fixed 
length. 

5. An object as described in 4 wherein one address of 
said set of endpoint addresses is a data element in 45 
the range of 24-128 bytes long. 

6. An object as described in claim 5 wherein 4 bytes 
of said one address is a server computer system 
network address and 2 bytes of said one address so 
is a server computer process network port number. 

7. An object as described in claim 1 wherein said set 
of endpoint addresses includes a server computer 
system network address and a server computer ss 
process network port number. 

8. An object as described in claim 1 wherein the dis- 



tributed object operating environment includes a cli- 
ent resident in a client computer process executing 
on a client computer system and said set of end- 
point addresses and said incarnation number to- 
gether indicate that said server computer process 
is said client computer process. 

9. An object as described in claim 1 wherein the dis- 
tributed object operating environment includes a cli- 
ent resident in a client computer process executing 
on a client computer system and said set of end- 
point addresses and said incarnation number to- 
gether indicate that said server computer system is 
said client computer system. 

10. An object as described in claim 1 wherein said in- 
carnation number is a data element of variable 
length. 

11. An object as described in claim 10 wherein said in- 
carnation number is a data element of fixed length. 

12. An object as described in claim 11 wherein said in- 
carnation number is a data element in the range of 
1-16 bytes long. 

13. An object as described in claim 1 wherein said in- 
carnation number is a number indicating the crea- 
tion time of said server computer process. 

14. An object as described in claim 1 wherein said in- 
carnation number is a predefined number which has 
a predefined meaning to the server computer proc- 
ess. 

15. An object as described in claim 1 wherein said ob- 
ject key is an identifier which in conjunction with said 
set of addressing information and said incarnation 
number uniquely defines said transient server ob- 
ject. 

16. An object as described in claim 1 5 wherein said ob- 
ject key is a identification number unique within said 
server computer process. 

17. An object as described in claim 1 wherein said dis- 
tributed object operating environment is a first dis- 
tributed object operating environment, and wherein 
said object key includes a second object for use as 
a second object reference for a transient object of 
a second distributed object operating environment. 

18. An object as described in claim 17 wherein said ob- 
ject key enables a client in said first distributed ob- 
ject operating environment to call said transient ob- 
ject of said second distributed object operating en- 
vironment. 
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19. A transient server object corresponding to an object 
reference as described in claim 1 , said transient 
server object having transient state associated with 
it, said transient state stored in transient memory 
on said server computer system. 

20. A transient server object as recited in claim 19 
wherein said transient server object is bound direct- 
ly to said server computer process such that when 
said server computer process ceases, said tran- 
sient server object ceases to exist. 

21. A distributed object operating environment com- 
prising: 

a plurality of computer systems; 

a computer network interconnecting said plu- 
rality of computer systems; and 

at least one object as recited in claim 1 , said at 
least one object residing on one of said plurality 
of computer systems. 

22. A distributed object operating environment as de- 
scribed in claim 21 further including a second object 
for use as an object reference for a persistent ob- 
ject, said persistent object intended to reside in a 
second server process executing on a second serv- 
er computer system, said second object having a 
data structure including: 

a computer system name corresponding to a 
computer system on which a locator service ex- 
ists; 

a locator identification corresponding to a dae- 
mon computer process under which said loca- 
tor service resides; 

an object key corresponding to said persistent 
object; and 

a subobject identifier. 

23. A distributed object operating environment as de- 
scribed in claim 22 wherein said data structure of 
said second object further includes a kind field indi- 
cating that the kind of said object is persistent. 

24. A distributed object operating environment as de- 
scribed in claim 22 wherein said data structure of 
said second object further includes a location hint. 

25. A distributed object operating environment as de- 
scribed in claim 23 wherein said location hint in- 
cludes: 



a set of endpoint addresses corresponding to 
said second server computer system upon 
which said persistent server object resides; and 

5 an incarnation number corresponding to said 

second server computer process, 

such that said set of endpoint addresses, said 
incarnation number, and said object key 
70 uniquely identify and locate said persistent 

server object. 

26. A distributed object operating environment as de- 
scribed in claim 22 further including: 

is 

a third object kind for use as an object reference 
for a null object; and 

a fourth object kind for use as an object refer- 
20 ence for an invalid object. 

27. An object for use as an object reference for a per- 
sistent object, said persistent object intended to re- 
side in a server computer process executing on a 

2S server computer system in a distributed object op- 
erating environment contemplating a plurality of dis- 
tributed transient objects, said object having a data 
structure comprising: 

30 a computer system name corresponding to a 

computer system on which a locator service ex- 
ists; 

a locator identification corresponding to a dae- 
35 mon computer process under which said loca- 

tor service resides; 

an object key corresponding to said persistent 
object; 

40 

a subobject identifier; and 
a location hint. 

45 28. An object as described in claim 27 wherein said lo- 
cation hint includes: 



a set of endpoint addresses corresponding to 
said server computer system; and 

an incarnation number corresponding to said 
server computer process, 

such that said set of endpoint addresses, said 
incarnation number, and said object key 
uniquely identify and locate said persistent ob- 
ject. 
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29. An object as described in claim 28 wherein said 
computer system on which a locator service exists 
is said server computer system. 

30. An object as described in claim 27 wherein said da- 
ta structure of said object further includes a kind 
field indicating that the kind of said persistent object 
is persistent. 

31. A distributed object operating environment com- 
prising: 

a plurality of computer systems; 

a computer network interconnecting said plu- 
rality of computer systems; and 

at least one object as recited in claim 27, said 
at least one object residing on one of said plu- 
rality of computer systems. 

32. A persistent server object corresponding to an ob- 
ject reference as described in claim 27, said persist- 
ent server object having persistent state associated 
with it, said persistent state stored in persistent 
memory on said server computer system. 

33. A persistent server object as recited in claim 32 
wherein said persistent server object is operable to 
persist such that when said server computer proc- 
ess ceases, said persistent server object maintains 
its state. 

34. A computer implemented method for maintaining 
distributed object addressing information in a cache 
memory on a computer system, said computer sys- 
tem for use in a distributed object operating envi- 
ronment, said method comprising the steps of: 

receiving under computer control an object ref- 
erence, said object reference corresponding to 
a distributed object; and 

determining under computer control if said ob- 
ject reference includes addressing information 
corresponding to said distributed object and, if 
so, writing under computer control said ad- 
dressing information into said cache. 

35. A method as recited in claim 34 wherein said step 
of receiving an object reference further includes a 
step of un marshaling under computer control said 
object reference. 

36. A method as recited in claim 35 wherein said step 
of receiving an object reference is part of a target 
object call. 



37. A method as recited in claim 35 wherein said step 
of receiving an object reference is part of a re- 
sponse to a target object call. 

5 38. A method as recited in claim 34 wherein said step 
of writing said addressing information includes writ- 
ing under computer control an expiration date for 
said addressing information into said cache. 

10 39. a computer implemented method for calling a dis- 
tributed server object which is intended to reside on 
a server process executing on a server computer 
system, said server object having a corresponding 
object reference which resides in a client process 
15 executing on a client computer system, said method 
comprising the steps of: 

acquiring under computer control addressing 
information for said distributed server object; 

20 

selecting under computer control an address 
for said distributed server object; and 

sending under computer control a request to 
25 said distributed server object. 

40. A method as recited in claim 39 further including the 
step of receiving under computer control a re- 
sponse from said distributed server object. 

30 

41. A method as recited in claim 39 wherein said step 
of acquiring addressing information includes the 
substep of determining under computer control the 
kind of said distributed server object, said kinds in- 

35 eluding transient and persistent. 

42. A method as recited in claim 41 wherein said kinds 
further include null and invalid, and wherein said 
step of acquiring addressing information further in- 

40 eludes the substep of returning under computer 
control an error message if the kind of said distrib- 
uted server object is null or invalid. 

43. A method as recited in claim 41 wherein said step 
45 of acquiring addressing information further includes 

the substep of returning under computer control 
said address information directly from said object 
reference if the kind of said distributed server object 
is transient. 

so 

44. A method as recited in claim 41 wherein said step 
of acquiring addressing information further includes 
the substeps of: 

55 determining under computer control if said ad- 

dress information is stored in a cache memory 
located on the client computer system; and 
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returning under computer control said address 
information from said cache memory if the kind 
of said distributed server object is persistent. 

45. A method as recited in claim 44 wherein it is deter- 
mined that said addressing information is not initial- 
ly stored in said cache memory and, as a result, the 
step of acquiring addressing information further in- 
cludes the intermediate substeps of: 

obtaining under computer control said address- 
ing information from within said distributed ob- 
ject operating environment; and 

storing under computer control said addressing 
information in said cache memory. 

46. A method as recited in claim 45 wherein said object 
reference includes a locator identification, a host 
name, and an object key, and wherein said step of 
obtaining said addressing information includes the 
substeps of: 



issuing under computer control a look-up oper- 
ation to said daemon process, passing said ob- 
ject key to said daemon. 

47. A method as recited in claim 46 wherein said step 
of establishing computer communications with a 
daemon process includes the step of determining 
under computer control if a transient object refer- 
ence for said daemon is stored in a cache memory 
found on said client computer system and, if so, said 
step of establishing communications further in- 
cludes the step of returning under computer control 
said transient object reference from said cache 
memory. 

48. A method as recited in claim 47 wherein it is deter- 
mined that said transient object reference is not 
stored in cache memory and, as a result, said step 
of establishing communications with a daemon 
process further includes the intermediate steps of: 

calling under computer control a remote proce- 
dure call binder on the server computer system 
using said host name, said calling step includ- 
ing passing said locator identification with a 
predetermined incarnation number; 



object reference for said daemon, said tran- 
sient object reference constructed from said 
address and said predetermined incarnation 
number; and 

storing under computer control said transient 
object reference in said cache memory. 

49. A method for calling a distributed server object as 
recited in claim 39 wherein said step of selecting an 
address includes the step of determining under 
computer control if said server process and said cli- 
ent process are the same process. 

50. A method as recited in claim 49 further including the 
step of selecting under computer control a local ad- 
dress and a local transport if said client process and 
said server process are the same process. 

51. A method as recited in claim 49 wherein it is deter- 
mined that said client process and said server proc- 
ess are not the same process and said method fur- 
ther includes the steps of: 

determining under computer control if said 
server computer system is the same as said cli- 
ent computer system; 

selecting under computer control a shared 
memory address and a shared memory trans- 
port if said server computer system is the same 
as said client computer system; and 

selecting under computer control a remote ad- 
dress and a remote transport if said server com- 
puter system is not the same as said client com- 
puter system. 

52. A computer implemented method for maintaining 
addressing information for a distributed object in a 
plurality of caches, each cache resident on a corre- 
sponding computer system, each computer system 
for use in a distributed object operating environ- 
ment, said method including the steps of: 

distributing under computer control all address- 
ing information for distributed objects available 
in said plurality of caches, said all addressing 
information distributed in the form of a plurality 
of object references sent to at least one com- 
puter system; and 

said at least one computer system performing 
the computer implemented method of claim 34 
for the distributed plurality of object references. 
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receiving under computer control an address ss 
from said remote procedure call binder call; 

constructing under computer control a transient 

17 



establishing under computer control computer 
communications with a daemon process run- 25 
ning on the server computer system; and 



EP 0 737 916 A1 




18 



EP 0 737 916 A1 



30 



Mass 
Storage 




19 



EP 0 737 916 A1 




20 



EP 0 737 916 A1 




EP 0 737 916 A1 




EP 0 737 916 A1 



400 



406 




418 



500 



510. 



420 



422 



424 



426 



428 




501 



OBJREF 
KIND: TRANSIENT 


SET OF 
ENDPOINT 
ADDRESSES 


INCARNATION 
NUMBER 


KEY 



502 



504 



506 



511 



OBJREF 
KIND: PERSISTENT 


HOST 
NAME 


LOCATOR 
ID 


KEY 


SUBOBJECT 
IDENTIFIER 


LOCATION 
HINT 



512 514 516 518 

Jig. 56 



520 



23 



EP 0 737 916 A1 



600 



602 



CLIENT INVOKES 
SERVER OBJECT 



ACQUIRE ADDRESSING 
INFORMATION OF 
SERVER OBJECT 



-604 



CHOOSE ADDRESS 




r 


SEND Rl 
TOADI 


EQUEST 
DRESS 



606 



^608 




614 



24 



EP 0737 916 A1 




708 



25 



EP 0 737 916 A1 




802 



.804 



806 



)ES THIS OBJECT RUI 
IN CLIENT PROCESS?. 



YES 



.X. 



USE LOCAL ADDRESS 
AND LOCAL TRANSPORT 



IS THE OBJECT 
SERVER RUNNING ON 
THE SAME HOST-AND IS 
SHARED ADDRESSING 
AVAILABLE? 



.810 



812 



YES 



1 


NO 

r 


USE REMOT 

Ar 

REMOTE Tl 


E ADDRESS 
iD 

FtANSPORT 



USE SHARED MEMORY 

ADDRESS AND 
SHARED TRANSPORT 



814 




26 



EP 0 737 916 A1 




GET TRANSIENT OBJREF 
FOR ORB DAEMON USING 
LOCATORJD AND HOST.NAME 



X 

ISSUE LOOK-UP OPERATION TO 
OBJREF; PASSING OBJECT KEY 
FROM PERSISTENT OBJECT 




Ty.9 



27 



» 



EP 0 737 916 A1 




1002 



IS TRANSIENT OBJREI 
FOR ORB DAEMON 
JN CACHE-2?. 

no" 



CALL RPC BINDER ON HOST.NAME 
PASS LOCATORJD AND 
PREDETERMINED INCARNATION NUMBER 



-1006 



1008 



CONSTRUCT TRANSIENT OBJREF WITH 
ADDRESS RETURNED FROM RPC BINDER 
AND PREDERMINED INCARNATION NUMBER 



STORE TRANSIENT 
OBJREF IN CACHE-2 


> 


'< 




RETURN 


OBJREF 



1010 



1012 




DONE 



1014 



28 



EP 0 737 916 A1 




<Pg.ll 



29 



EP 0 737 916 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



EP 96 30 1655 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



of 



I in4kat»n, where appropriate, 



Relevant 

to i 



CLASSIFICATION OF THE 
APPLICATION (IbLC16) 



PROCEEDINGS OF THE INTERNATIONAL 
CONFERENCE ON DISTRIBUTED COMPUTIN 
SYSTEMS, PITTSBURGH, MAY 25 - 28, 1993, 
no. CONF. 13, 25 May 1993, INSTITUTE OF 
ELECTRICAL AND ELECTRONICS ENGINEERS, 
pages 5G8-515, XPOB0399423 
MILLARD B R ET AL: "RUN-TIME SUPPORT AND 
STORAGE MANAGEMENT FOR MEMORY -MAPPED 
PERSISTENT OBJECTS" 

* page 508, left-hand column, line 27 - 
line 41 * 

* page 509, left-hand column, line 8 - 
line 31 * 

* page 511, right-hand columi, line 53 - 
page 512, left-hand column, line 54 * 

PROCEEDINGS OF THE SECOND INTERNATIONAL 
WORKSHOP ON OBJECT ORIENTATION IN 
OPERATING SYSTEMS (CAT. N0.92TH9477-0) , 
DOURDAN, FRANCE, 24-25 SEPT. 1992, ISBN 
0-8186-3015-9, 1992, LOS ALAMITOS, CA, 
USA, IEEE COMPUT. SOC. PRESS, USA, 
pages 212-220, XP082O99478 
DAVE A ET AL: 'Proxies, application 
interfaces, and distributed systems" 

* page 213, left-hand column, line 45 - 
right-hand column, line 1 * 

* page 214, left-hand column, line 8 - 
page 218, left-hand column, line 20 * 



1-52 



G96F9/44 



1-52 



TECHNICAL FIELDS 
SEARCHED OsLCLd* 



G86F 



The 



i orawn ap for all i 



THE HAGUE 



26 July 1996 



Brandt, J 



CATEGORY OF CITED DOCUMENTS 



X: pmtadariy idenM if tikea time 

Y : partkalarty relevant if camMac* with another 

■Dcwiit of the %m 
A : techaofaeic*! back^rtxme" 
O : non-wrirtm dlscftosaw 



T t theory or oriaciale nodetlyiag tbe inmotioa 
E : earner patent coaineBt, bat puMiAH an, or 

alter tbe filing date 
D : eoauBcat diet in tbe application 
L : docmaent died for other reasons 

ber of the xaote patent family, corresponding 



30 



